\chapter{Einführung}

% Der Transport von Gütern sowie die Mobilität der Bevölkerung sind wichtige Voraussetzungen für das reibungslose Funktionieren unserer Gesellschaft und beeinflussen maßgeblich die Lebensqualität sowie die Wettbewerbsfähigkeit der Wirtschaft. Im Hinblick auf aktuelle ökologische und ökonomische Fragestellungen gewinnen der Schienen- und der Binnenschifffahrtsverkehr immer stärker an Bedeutung. \cite{pilonav-hp}	%TODO Zitierweise

Die zunehmende Autonomisierung sowie die Assistenzsystem-gestützte Steuerung von Fahrzeugen verlangt nach umfangreichen und wiederholbaren Feldtests. Besonders im Bereich der Satellitennavigation sind diese Praxisversuche nicht nur sehr kostenaufwändig sondern insbesondere nicht reproduzierbar.

Im \acf{PiLoNav} Projekt des \acf{DLR} soll unter anderem eine Verbesserung der Positionslösung aus \acf{GPS}-Signalen durch das Hinzuziehen terristrischer Sensorik erreicht werden.

Ein weiteres Anwendungsbeispiel des Projekts ist das Ermitteln von Gleisabschnitten, die geschmiert werden müssen. Hierfür werden u.a. die Daten eines Mikrofons und die \acs{GPS}-Rohdaten synchron erhoben.

Um diese Anwendungen zu validieren und unterschiedliche Ansätze messbar miteinander zu vergleichen bietet es sich also an eine einzige Testfahrt mit entsprechender Messtechnik durchzuführen. Dann kann die zu testenden Komponenten im Labor unter immer gleichen Voraussetzungen überprüft werden, da die aufgenommenen Daten sich nicht von Testlauf zu Testlauf ändern.
So können verschiedene Komponenten und entwickelte Algorithmen anhand der gleichen Ausgangsbasis, nämlich den aufgenommenen Rohdaten, verglichen werden. Eine solche Testfahrt kann bis zu acht Stunden dauern.

Zur Realisierung dieses Ansatzes und als Ausgangspunkt für diese Forschungsrichtung wurde in Zusammenarbeit mit der Firma NOFFZ ein System zusammengestellt, welches die \acf{HF}-Umfelddaten, sowie beliebige weitere Sensordaten aufnimmt. Dieses System besteht aus zwei \acf{PXI}-Systemen der Firma National Instruments, da die Verarbeitung der \acs{HF}-Umfelddaten zusammen mit den Daten der zusätzlich angeschlossenen Sensoren die Kapazität eines einzelnen Messsystems übersteigt. Des Weiteren ist die Aufnahme der \acs{HF}-Rohdaten über eine fertige Lösung von Averna, dem \acf{URT} bereits fertig realisiert und kann nicht ohne weiteres erweitert werden, so dass die Nutzung eines zweiten, frei programmierbaren Systems nötig wird. 
Diese beiden Systeme müssen eine synchrone Aufnahme der Daten gewährleisten, was Kern dieses Belegs ist.	\pdfmargincomment[style=todo]{oder hat man das gemacht, weil GPS schon fertig war und somit nur die zusätzlichen Daten hinzukommen?} %TODO oder hat man das gemacht, weil GPS schon fertig war und somit nur die zusätzlichen Daten hinzukommen?

Um das Gelingen des Softwareprojekts zu gewährleisten wird als Überbau die Wasserfallmethode (nach \cite[S.~228]{tinf}) aus dem Bereich des Softwaremanagements herangezogen.  Dabei wird mit Analyse und Entwurf begonnen. Darauf folgte die Implementierung und Validierung der erdachten Softwaremodule. Da im Entwurf ersichtlich wird, dass die einzelnen Module komplett unabhängig voneinander betrachtet werden können, werden die jeweiligen Softwaremodul einzeln abgeschlossen, also implementiert und validiert, bevor zum nächsten Modul übergegangen wird.

Für die Softwareentwicklung auf dem \acs{NF}-System wird die grafische, datenflussorientierte Programmierumgebung \acf{LabVIEW} verwendet. Diese Programmierumgebung wurde von den zwei Gründern der Messtechnikfirma National Instruments, Jim Truchard und Jeff Kodosky erfunden, um die Software ihrer Messgeräte ähnlich wie diese selbst zu strukturieren, so dass ein einzelner Programm-Baustein \acf{VI} genannt wird\footnote{Ein \acs{VI} kann als eine Funktion in C oder ähnlichen imperativen Programmiersprachen angesehen werden. Ein \acs{VI} hat Ein- und Ausgänge, die als Funktionsparameter und Ausgabewerte (ggf. in mehrdimensionaler Form eines \texttt{struct}s) verstanden werden können}. (nach \cite[S.19]{LVE}) Die Programmierung lehnt an Flussdiagrammen an und soll für die Zielgruppen der Firma, die meist wenig oder keine Programmiererfahrung haben, leicht verständlich und nachvollziehbar sein. \acs{LabVIEW} ist seit der ersten Version im Jahre 1986 (damals für Macintosh-Computer) allerdings zu einer umfangreichen Hochsprache gewachsen, die viele Vorteile einer etablierten Programmiersprache wie C oder Java bietet und sich zusätzlich einer Prozessvisualisierung bedient. In der Programmierumgebung gibt es für jedes \acs{VI} ein Frontpanel, welches der Bedienoberfläche eines Messgeräts (Panel) nachempfunden ist und ein Blockdiagramm, was den Quellcode in Form eines Datenflussdiagramms darstellt. Dabei besitzen die Ein- und Ausgänge am Frontpanel korrespondierende Elemente im Blockdiagramm. Abbildung~\ref{pic:LabVIEW Frontpanel und zugehöriges Blockdiagramm} zeigt ein Minimalbeispiel in \acs{LabVIEW}.

Dieses \acs{VI} wird bis zum Betätigen der \texttt{Stopp}-Schaltfläche ausgeführt und errechnet die \texttt{Summe} aus \texttt{a} und \texttt{b}. In der oberen rechten Ecke des Frontpanel-Fensters (links) sind das Anschluss- und Symblofeld des \acs{VI}s zu sehen. Im Anschlussfeld können die Anzeige- und Bedienelemente des Frontpanels verankert werden, so, dass das \acs{VI} bei der Verwendung als \acf{SubVI}\footnote{Die Verwendung eines \acs{VI}s als \acs{SubVI} entspricht einem Funktionsaufruf in einer befehlsorientierten Programmiersprache. Dabei ist das \acs{SubVI} als die im \acs{VI} aufgerufene Funktion anzusehen.}, innerhalb eines anderen \acs{VI}s diese als Ein- und Ausgänge verwendet. Im übergeordneten \acs{VI} wird das im Symbolfeld definierte Bild verwendet.   

\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/LV}	%Breite und Pfad
	\caption{LabVIEW Frontpanel und zugehöriges Blockdiagramm}		%Bildunterschrift
	\label{pic:LabVIEW Frontpanel und zugehöriges Blockdiagramm}	%Referenz zum Verlinken
\end{figure}
